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(54) Techniques for establishing and managing a distributed credentiai store 



(57) Methods and systems are provided tor estab- 
lishing and managing a distributed credential store. An 
identity service (410) aggregates identity information 
from one or more identity stores and maintains the in- 
formation as a remote credential store (303,411 ). Initial- 
ly, the remote credential store, or portions thereof, is 
transmitted to a principal service (420) as an initial con- 
figuration of a local credential store (302,425). A princi- 



pal interacts with the principal service for defining or 
modifying a policy that identifies portions of the remote 
credentiai store which are to be synchronized With the 
focat credential store. In some embodiments, the prin- 
cipal interacts with the principal service for defining a 
local policy that identifies portions of the local credential 
store (302) which are not synchronized with the remote 
credential store (303). The interactions between the cre- 
dential stores are trusted and secured. 



10CNL 
STORE® 



o 
to 



111 



*I5 


mWPH. IDD.T1RER f&D(S) 


-40! 




CRE0EN51OG NFORMATOi RECORD® 


-402 




Primodbjj Jouwt. JEOQl PAfES (Fft; 



EP 1 560 100 A1 



Field of the invention 

[0001] Ths invention relates generally to network se- 
cu rity, and more specifically to tech n iques f o r establish- 
ing and managing a distributed credential store. 

Background of the invention 



[0002] As individuals continue using the Internet for 
connecting to a myriad of services and resources, a va- 
riety of confidential information and identity information 
about those individuals needs to be managed, synchro- 
nised, and securely distributed- In many instances, this 
information is concurrently and manually managed in 
environments local to the individuals, in local enterprise 
environments associated with the individuals, and In en- 
vironments that are local to the services and resources. 
[0003] Having the identity and confidential informa- 
tion housed and managed in a variety of environments 
presents a number of challenging problems. For exam- 
ple, individuals are not always properly authenticated in- 
to their enterprise environment, which means that ac- 
cess to some information may not be available to indi- 
viduals who use different computing devices from time 
to time and who are not properly logged into their ap- 
propriate enterprise environments from time to time. Ad- 
dillonaliy, management of the identity and confidential 
information usually occurs in multiple environments. 
That is, an individual maintains some information, the 
enterprise maintains other information, and the services 
or resources maintain still other information, in some 
cases, the same information is separately managed in 
duplicate. This creates synchronization problems for the 
individuals and for network administrators. 
[0004] Furthermore, the information, as it is being 
managed and manually maintained or utilized, becomes 
unduly exposed during network transmissions. This 
means that each time portions of the information are 
transmitted for purposes of authentication orfor purpos- 
es of synchronization it can become compromised and 
intercepted. This results in a variety oi security issues 
which must be established for network interactions that 
involve the transfer of the information. 
[0005] Typically, security measures will entail estab- 
lishing trust relationships utilising public- private key 
pairs with encryption and the like. The encryption is used 
in secure communications for minimizing exposure to 
confidential information and identity information. How- 
ever, mobile individuals may not have static key pairs 
with services and may often use a laptop to connect from 
a variety of internet Service Providers (ISPs), such that 
the individuals do not have static Internet Protocol {IP) 
addresses which can uniquely and securely establish 
the needed trusted relationships between the individu- 
als and other services or resources. Consequently, in- 
dividuals are often limited in their use of or prohibited in 



their use of certain confidential and identity information 
in many contexts when adequate security measures are 
enforced in conventional manners. 
[0008] Thus, even the most elaborate conventional 
5 techniques that attempt to automate and synchronize 
an individual's confidential information and identity in- 
formation still falls short of providing a consistent level 
of sustainable service , because i n many cases th e user 
is unable to effectively access some of his/ her needed 
10 information. 

[0007] Thus, there is a need for establishing and man- 
aging a distributed credential store, where that creden- 
tial store can be securely accessed, better managed, 
and consumed in order to provide an improved level of 
15 consistent service. 

Summary of the Invention 

[0008] The present invenlion provides methods and 
20 systems for establishing and managing a distributed 
credential store, in accordance with claims which follow. 
In various embodiments of the invention, techniques are 
presented for establishing and managing a distributed 
credential store. An identity service interacts and man- 
25 ages one or more idenlity stores associated with a prin- 
cipal. The idenlity service and the principal interact ac- 
cording to a trust specification, such that ail communi- 
cations are secure. Initially, the identity service creates 
an initial configuration instance of a distributed creden- 
30 tial stare for She principal according to a synchronization 
policy which is created and maintained by the principal, 
The synchronization policy defines fields of a remote 
credential store which are to be kept in synch with a local 
credential store. 
35 [0009] The local credential store is managed by the 
principal in a processing environment that is local to the 
principal. The identity service generates a remote cre- 
dential store which it maintains to synchronize records 
of the local credential store with affected records of the 
40 one or more identity stores. The synchronization is driv- 
en by the synchronization policy. 
[0010] If the principal fails out of communicatio n with 
the identity service and subsequently re- establishes 
communication, then the identity service uses the syn- 
43 chronlzation policy communicated from the principal to 
generate a new active instance of the remote credential 
store and bring the principal's local credential store and 
the remote credential store into synch with one another 
according to the synchronization policy. The principal 
can maintain personal entries in the local credential 
store which are not communicated to and synchronized 
by the identity service into the remote credential store. 

Brief Description of the Drawings 

{D0113 

FIG 1 is a flowchart representingamethod for man- 
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aging a distributed credential store; 

FIG. 2 is a flowchart representing another method 
for managing a distributed credential store; 

FIG. 3 is a diagram of a distributed credential man- 
agement system; and 

FIG. 4 is a diagram representing a distributed cre- 
dential store. 

Detailed Description of the Invention 

[0012] in various embodiments of the invention, the 
term " principal" is used. A principal is an electronic rep- 
resentation of an entity. An entity can be a resource, a 
user, an agent, an application, a system, a service, a 
group, a department, an object, etc. An entity consumes 
inlormation, provides information, or provides a service 
to other entities over a network. Moreover, an entity can 
perform combinations of the above-mentioned opera- 
tions. 

[0013] In one embodiment, the term principal is con- 
sistent with how that term is generally understood in tho 
security arts. For example, the term principal can be 
ujsed in the context of Security Assertion Markup Lan- 
guage (SAML) which is an extension of the Extensible 
.Markup Language (XML). SAML is used for securely 
processing assertions about a user or application (e. g., 
principal). More recently, SAML has been extended with 
technology referred to as Liberty. Liberty is part of the 
Liberty Alliance Project (LAP) and is attributed to open 
interoperable standards for federated network identi- 
ties.- Thus, the term principal can also be used in the 
context of Liberty technologies. 
[0014] A SAML encoded statement includes an as- 
sertion, a protocol, and a binding. There are generally 
three types of assertions; an authentication assertion 
used to validate a principal's electronic identity, an at- 
tribute assertion that includes specific attributes about 
the principal, an authorization assertion that identifies 
what the principal is permitted to do (e. g„ poiicies).The 
protocol defines how a SAML processing application will 
ask for and receive the assertions. The binding defines 
how SAML message exchanges are mapped to Simple 
Object Access Protocol (SOAP) exchanges, or other 
proiocol exchanges. 

[0015] In general terms, SAML techniques improve 
security between business- to-business (B2B) electron- 
ic transactions and business- to- customer (B2C) elec- 
tronic transactions. The techniques permit one principal 
to !og in with a single transaction to a receiving principal 
and then use a variety of the receiving principals dispa- 
rate services by providing the SAML statements when 
needed. SAML techniques are not limited to inter- or- 
ganization relationships {e. g, B2B or B2C); the tech- 
niques can be used within a single organization j r.irs- 
organization). SAML techniques are supported with a 



variety of network protocols, such as Hypertext Transfer 
Proiocol (HTTP), Simple Mail Transfer Protocol 
(SMTP), File Transfer Protocol (FTP), SOAR BizTalk. 
and Electronic Business XML (ebXML). The Organiza- 
tion for the Advaneemeni of Structured Information 
Standards (OASIS) is the standards group for SAML. 
The techniques of Liberty are enhancements to the 
SAML techniques and may also be used in connection 
with various embodiments of this invention. However, it 
io is to be understood that SAML and Liberty techniques 
are not needed to perform the teachings of all embodi- 
ments of the invention. These techniques complement 
some embodiments of this invention. In this sense, the 
integration of SAML and Liberty techniques with some 
15 of the embodiments presented herein is intended to be 
part of certain aspects of this invention, but not all em- 
bodiments of this invention are dependent on SAML or 
Liberty technology. In asimilarmannerthere are various 
other existing authentication techniques that may be 
practiced in connection with some embodiments of this 
invention. But, once again these other authentication 
techniques are not necessary for realizing the benefits 
of all embodiments of the invention. Some of these tech- 
niques include Public Key Infrastructure (PKI) tcch- 
*s niques including public- private key pairs, digital certifi- 
cates, biometrie authentication, or use of conventional 
identifications and passwords. 
[0016] A credential store is a file, database, directory, 
orcombinations of the same which house(s) confidential 
30 information and identity information about one or more 
principals. The confidential information is defined by at- 
tribute fields that identify a type of confidential data; 
each attribute field is populated with specific attribute 
values which identify the values associated with confi- 
35 dential data. A credential store also includes identity/ au- 
thentication information and or authentication tech- 
niques or services associated with authenticating prin- 
cipals vis-a-vis other principals. In some cases the iden- 
tity information is a legacy identification and password 
-to pair, in other cases, the identity information is a certifi- 
cate or an assertion, such as a SAML or Liberty asser- 
tion that identifies what identity information is needed to 
authenticate and how that authentication is to take 
place. 

■>5 {0017] The credential store aiso includes policies that 
define how attributes can or cannot be processed In a 
given principal- lo- principal relationship. The authenti- 
cation information, authentication techniques/ services, 
attributes, and policies combine to form credentialing in- 

*> formation records that populate the credential store. 
Furthermore, a credential store need not reside contig- 
uously within storage or memory. That is, a credential 
store can be logically assembled from a variety of other 
identity stores residing in a plurality of remote storage 
and memory locations. 

[0018] A dratrbuted credential store is one that is 
maintained locally from within a beai environment of a 
principal, but incorporates and synchronizes in whole or 
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in part with a remote credential store. A single distribut- 
ed credential store can be associated with a single prin- 
cipal. Alternatively, a single distributed credential store 
can be used to manage a plurality of principals. In this 
latter-embodiment, each entry within the distributed cre- 
dential store is uniquely encrypted for a particular prin- 
cipal's use. 

[0019] Various embodiments of this invention can be 
implemented in existing network products and services. 
For example, in some embodiments, the techniques 
presented herein are implemented in whole or in part in 
the iChain <B, Border Manager ®, and Excelerator ® 
products distributed by Novell, Inc., ot Provo, Utah. Of 
course, the embodiments of the invention can be imple- 
mented in a variety of architectural platforms, systems, 
or applications. For example, portions of this invention 
can be Implemented in whole or in part in any distributed 
architecture platform, operating systems, proxy servic- 
es, or browser/ client applications. Any particular archi- 
tectural layout or implementation presented herein is 
provided for purposes of illustration and comprehension 
oniy and is not intended to limit aspects of the invention. 
[0020] FIG. 1 is a flowchart representing one method 
100 for managing a distributed credential store. The 
method 1 00 is implemented as one or more applications 
or services which reside in a computer- accessible me- 
dium and is accessible over a network. Some portions 
of the processing of the method 100 (hereinafter 
"processing") operates in an external computing envi- 
ronment from a principal while other portions of the 
processing operates in a local computing environment 
of the principal. The two processing portions are inter- 
faced using any existing or customized protocols and 
application programming interfaces (APIs). In some em- 
bodiments, a principal's local processing interfaces with 
the external processing via a World- Wide Web (WWW) 
browser operating within a client of the principal. A client 
is a processing device from which the browser is oper- 
ating on. Initially, an identity service is in a trusted rela- 
tionship with one or more identity stores that house at- 
tribute and identity information about one or more prin- 
cipals. The identity service is capable of authenticating 
a principal and establishing a secure communication 
with fh at principal vis-a-vis other diflere nt principals with 
which the principal may interact, in some cases, that se- 
cure communication entails the identity service encrypt- 
ing communications and signing communications with 
public- private key pairs. The principal via a client serv- 
ice can decrypt the communications using its own pri- 
vate key and a public key associated with the identity 

[OQ21] A sample technique for secure and trusted re- 
lationships between a principal and an identity service 
can be found in our co-pending European patent appli- 
cation no. 041 06396.7 entitled ! " Techniques for Dynam- 
ically Establishing and Managing Authentication and 
Trust Relationships." 

[0022] Information and transactions that the principal 
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can send and receive from the identity service may exist 
in global policies defined in atrust specification between 
the identity service and the principal. The trust specifi- 
cation can be managed, owned, and controlled by ap- 
s propriate network administrators and modified as need- 
ed to enable or disable features of the present invention. 
The trust specification wi II also dictate the type of secure 
communications and methods used during interactions 
between the identity service and the principal. In some 
w cases, the identity service and the principal can com- 
municate with one another via SAML or Liberty asser- 
tions and their associated protocols. The trust specifi- 
cation also ensures that communications about a cre- 
dentiai store are secure and verifiable in order to main- 
's tain proper security. 

[0023] Initially, the principal desires to establish an in- 
itial instance of a distributed credential store. This en- 
tails creating a local credential store and a remote cre- 
dential store and a policy thai will drive the synchroni- 
se zation between the local and remote credential data 
stores. The interaction between the local and remote 
credential store and the results that it produces in the 
local credential store is an instance of the distributed 
credential store. 
25 [0024] One way to create an initial instance of the dis- 
tributed credential store is for the principal to request 
the initial instance (pull) from the identity service. Anoth- 
er way to create an instance is for the identity service or 
some other third- party lo independently request or gerr- 
30 erate an instance of the distributed credential store for 
a particular princ ipal (push). Thus, an Initial instance of 
a distributed credential store can be generated or cre- 
ated from either a push or pull model. 
[0025] Once a push or pull request is initially received, 
35 the identity service validates that the request is permis- 
stole and if it is generates an initial instance of a distrib- 
uted credential store. In one embodiment, the identity 
service generates the initial instance by inspecting a glo- 
bal contract associated with a particular principal and by 
<to inspecting the appropriate trust specification and global 
policies. The global contract defines how a principal is 
authenticated to various other principals using specific 
identifying information. The global contract also pro- 
vides information that permits the identity service to ac- 
45 quire appropriate attribute information for a given rela- 
tionship of the principal vis-a-vis other principals. 
[0026] The global policy may restrict certain relation- 
ships based on physical locations, time limitations, cal- 
endar day limitations, or specific predefined events 
so which limit certain relationships. The global contract 
identifies the specific identity stores which house the 
needed information needed by the identity service in or- 
der to construct an initial instance of the distributed cre- 
dential store. The trust specification identifies how the 
55 identity service and the principal will communicate with 
one another about the distributed credential store in or- 
der to satisfy themselves that each communication is 
secure and trusted. 
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[0027] Once the global contract, global policy, and 
trust specification are inspected and evaluated, records 
associated with the distributed credential store are gen- 
erated and either batched until entirely assembled or 
streamed individually as assembled using the secure s 
communications defined in the trust specif tcalion direct- 
ly to the principal. Each record includes a particular re- 
lationship between a principal vis-a-vis another principal 
and includes authentication information, authentication 
techniques/services, attributes, and policies. The au- to 
thentication information and authentication techniques/ 
services are used to authenticate the principal to anoth- 
er principal defined in the record. In some cases, the 
authentication information and authentication tech- 
niques/ services are represented as a certificate, and *5 
can be optionally provided as a SAML or Liberty asser- 
tion, The attribute information identifies confidential in- 
formation that can be accessed or not accessed during 
the relationship defined by the record. Policies are also 
included in the record that identifies the operations so 
which are permissible or not permissible against the at- 
tributes during a relationship defined by the record. 
Each record can be viewed as a credential for a partic- 
ular principal- to-principal relationship. 
[0028] The description presented above provides the 2$ 
context with which a distributed credential data store is 
initially established, configured, and communicated to 
thB local environment of a principal . 0 nee this in itial con- 
figuration is received it is established as a principal (lo- 
cal) credential store by the principal. 30 
[0029] The records established by the identity service 
form an enterprise credential store, which is maintained 
and managed by the identity service in concert with the 
principal credential store. Accordingly, at 110, portions 
of the enterprise credential store are associated or 35 
linked by the identity service to appropriate portions of 
the principal credential store, which is managed by a 
principal service of the principal. In one embodiment, at 
1 11 . the identity service selectively aggregates or main- 
tains metadata such as links associated with one or 
more records of appropriate identity stores as defined 
by apoiicy or contract associated with the principal. The 
identity service can maintain contents of selective iden- 
tity records or maintain links to the selective identity 
records of appropriate identity stores. These duplicated « 
records or maintained links form the enterprise creden- 
tial store which ihe identity service manages. 
[0030] The identity service is configured to detect 
when changes to the duplicated records or maintained 
iinks are made in the identity stores via a data store 
event that is trapped and monitored by ihe identity serv- 
ice. Thus, if an administrator alters a record of an identity 
store that the identity service is tracking as pari of the 
enterprise residential store, the identity service is in a 
position to acquire the changes and transmit, at 112 the 
changes to the principal credential store, if desired. 
[0031] The principal via its principal setvice commu- 
nicates an initial synchronization policy to the identity 
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service. With this synchronization policy, both the iden- 
tity service and the principal service know which por- 
tions of the enterprise credential store and the principal 
credential store are to be selectively synchronized wilh 
one another, as depicted at 120. 
[0032] The synchronization policy can be maintained 
by the principal service of the p rincipal . Th is has Ihe add- 
ed benefit of permitting the principal service and the 
identity service to synchronize after an initial configura- 
tion of the distributed credential store has been instan- 
tiated for a principal but where the principal drops out of 
communication with the identity service for some period 
of time. For example, suppose that a principal acquires 
an initial principal credential store from the identity serv- 
ice and the identity service generates an active enter- 
prise credential store related to the principal credential 

£0033] Now suppose that the principal logs off of or 
terminates communication wilh Ihe identity service for 
some extended period of time and then at a later time 
reestablishes communication with the identity service. 
The principal will have a principal credential store which 
may or may not have been modified during the lapse of 
non communication, and in a similar manner ono or 
more records that were previously associated with an 
active enterprise credential store may have changed 
during the period of non communication within one or 
more affected identity stores. The identity service can 
flutomatleally generate a new up- to- date Instance of a 
needed enterprise credential store and synchronize with 
any modified principal credential store via the principal's 
local synchronization policy which theprincipal commu- 
nicates during initial re- communication to the identity 
service. If there are conflicts between changes of the 
personal credentia! store and ihe newiy instantiated en- 
terprise credential store, the conflicts can be resolved 
by the policy, 

[0034] The principal, in some embodiments, may de- 
sire to mainlain some personal credential information 
associated with private business or affairs of the princi- 
pal separate and distinct from the management of the 
enterprise credential store. In these embodiments, at 
121, the principal can selectively insert this personal 
credential information into the principal credential store 
where it is maintained and managed by the principal 
service of the principal. However, if this personal infor- 
mation is defined by a local synchronization policy of the 
principal as information that is not to be synchronized 
with the enterprise credential store, then, at 122. the en- 
terprise credentia! store is prevented from acquiring or 
synchronizing with this personal credent ialing informa- 
tion. 

[0035] Conversely some new or modified identity in- 
formation can be inserted or changed by the principal 
within the principal credenti&J store, at 1 23, and accord- 
ing to the synchronization policy automatically commu- 
nicated to the identity service and updated to the enter- 
prise credential store. An update to the enterprise cre- 
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dentist store will force the identity service to update the 
effected records in the appropriate identity stores. 
[0036] in a like manner, at 124, if the synchronization 
policy dictates, any changes detected in the enterprise 
credential store will generate automatic updates to the 
appropriate records of the principal credential store. 
[0037] Ail interactions between the enterprise creden- 
tial store and the principal credential store occur accord- 
ing to the strictures of the overall trust specificatio n be- 
tween the identity service and the principal. Accordingly, 
at 1 30, all conflicts and communications are maintained 
in conformance with the trust specification and the over- 
all global policies and contracts heid between the iden- 
tity service and the principal. 
[0038] Moreover, the principal via the principal service 
can alter the synchronization policy and communicate 
the changes to the identity service at 132. This permits 
the principal to control what is and what is not synchro- 
nised. Of course, in some embodiments, a global policy 
or contract associated with the principal at the identity 
service level can constrain what portions of the policy 
which can be modified and driven by the principal. 
[0039] Embodiments of method 100 demonstrate 
how a principal can interact with an identity service for 
purposes of managing and controlling its own version of 
a credential store. This principal credential store can be 
encrypted and maintained in a local environment of the 
prin cipa! or on a client processing device of the principal. 
Each time the principal re- establishes communication 
with the identity service, the principal's synchronization 
policy can be used to re- synchronize the principal cre- 
dential store with an identity service generated enter- 
prise credential store. This permits a principal to move 
around and independently access needed credentialing 
information to successfully interact with other principals. 
1 1 also permits the pri ncipal to maintai n some information 
which is never synchronized to the enterprise or known 
to the enterprise. Moreover, no communication between 
the principal credential store and the enterprise creden- 
tial store occur outside of trusted communications de- 
fined by a trust specification, 

[0040] FIG. 2 is a flow diagram of another method 200 
for managing a distributed credential store. The method 
is implemented in a computer readable medium and is 
accessible over any network. The processing of the 
method 200 {hereinafter "processing") represents 
processing performed by a client or principal service that 
interacts with an identity service. In one embodiment, 
the interface between some portions of the processing 
and the identity service' is implemented within a WWW 
browser, in some embodiments, the processing is a 
service that manages a local credential store on behalf 
cf multiple principals that interact with the identity serv- 
ice, in this sense She local credential store can logically 
represent multiple unique principal credential stores as 
discussed above with FIG.i. AS 21 G. the processing es- 
tablishes and initiates a trusted and secure relationship 
with a remote credential store via an identity service. 
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The identity service has access to one or more identity 
stores associated with one or more principals. The iden- 
tity service logically assembles a remote credential 
store from the one or more identity stores on behalf of 
s the processing. The remote credential store includes 
one or more enterprise credential stores similar to what 
was discussed above with respect to FIG. 1 . The trust 
relationship between the generated remote credential 
store and the processing is defined and driven by a trust 
10 specification as depicted at 21 1 . 

[0041] At 220, the processing receives changes as- 
sociated with one or more entries in the remote creden- 
tial store into the local credential store. That is, a syn- 
chronization policy informs the identity service as to 
is which records or entries associated with whole records 
or portions o! records included within the remote cre- 
dential store which are to be automatically communicat- 
ed to the processing and updated to the appropriate af- 
fected entries of Ihe local credential store. For elficiency 
20 purposes, the processing can manage some portions of 
the local credential store from memory and some por- 
tions from storage as depicted at 22 1 . Agai n , at 222 , the 
entries that are synchronized into the local credential 
store and transmitted from the local credential store to 
25 the remote credential store are managed by a local syn- 
chronization policy which can be communicated in 
whole or in part to the identity service for purposes of 
managing the synchronization of the remote credential 
store. 

30 [0042] In one embodiment, at 223, the processing 
manages the local credential store for multiple unique 
principals. This may be advantageous when a single lo- 
cal credential store is servic ing a plurality of principals 
within a local network. In these instances, each entry 
35 within the local credential store is uniquely associated 
with a particular unique principal. Moreover, In some 
embodiments, each unique entry can be uniquely en- 
crypted in a manner such that only the associated prin- 
cipal knows the proper decryption algorithm. This per- 
40 mils the processing to securely service multiple princi- 
pals from a single local credential store. 
[0043] The local synchronization policy will permit the 
processing, at 224, to automatically communicate 
changes with entries in the local credential store to the 
45 remote credential store via its Identity service. As was 
discussed with FIG. 1 , some entries In the local creden- 
lial store will remain privale or personal to Ihe local cre- 
dential store and will therefore not be communicated to 
the remote credential store. Again, these personal era- 
se tries will be defined in the local synchronization policy 
and are not communicated or known to the remote cre- 
dential store via the identity service Accordingly, at 225, 
the processing manages some personal entries in the 
local credential store which are independent of and not 
55 communicated to or synchronized with the remote cre- 
dential store. 

[0044] At 23G : any defected changes to entries of the 
local credential store which are identified as entries 
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which the processing wants the remote credential store 
to synchronize with {via the local synchronization policy) 
are transmitted to the remote credential store via the 
identity service. 

[0045] The processing of FIG. 2 permits one or more 
principals to establish and manage a locai credential 
store which selectively synchronizes with a remote cre- 
dential store. The principals may from time to time drop 
out of communication with an identity service having the 
remote credential store; however the principals will still 
maintain and have direct access to the local credential 
store. The local credential store provides the principals 
with credentialing information that the principals can use 
toaulhenticatewith and interact with other different prin- 
cipals. When the principals re-establish communica- 
tions with the identity service, any changes which are 
desired to be synchronized with the remote credential 
storecan be automatically synchronized via trusted and 
secure communications defined by a trust specification 
between the processing and an identity service of the 
remote credential store. 

[O046J FIG. 3 is a diagram of a distributed credential 
management system 300. The distributed credential 
managcmont system 300 is implemented in a computer 
readable medium and accessible over a network, tn 
some embodiments, the distributed credential manage- 
ment system 300 implements the processing described 
above with respect to methods 100 and 200 of FIGS. 1 
and 2, respectively. The distributed credential manage- 
ment system 300 includes a trust specification 301, a 
local credential store 302, and a remote credential store 
303. The local credential store 302 resides in the local 
computing environment of one or more principals 330. 
In one embodiment, the local credential store 302 re- 
sides' on a client of a particular principal 330. In another 
embodiment, the local credential store 302 resides with- 
in a local secure network that is accessible to multiple 
principals 330. 

[0047] Conversely, the remote credential store 303 
res ides remotely an rj extern a! to th e local computin g en- 
vironment of the principal 330. ft is accessible via a net- 
work 304. The remote credential store is logically as- 
sembled and associated with selective attributes and 
identity information about the principaf 330 and acquired 
from or maintained from one or more identity stares. 
[0048] The local credential store 302 and the remote 
credential store 303 interact with one another via the 
network 304 with secure communications defined by the 
trust specification 301 , The synchronization between 
entries of the remote credential store 303 and the local 
credential store 302, and vice versa, are driven by syn- 
chronization policies 310 and 320. 
[0049] The local credential store 302 includes a focal 
synchronization policy 31 0 which drives and defines the 
remote synchronization poiicy 320. The principal 330 
1 ' 1 ' " aii.in policy 31 0 by identify- 

ing entrios from the remote credential store 303 which 
are to be automatically synchronized with entries cf the 



local credential store 302. The principal 330 also defines 
entries or portions of the local synchronization policy 
31 0 which are to be synchronized and not synchronized 
with the remote credential store 303. The entries or por- 
s tions to be synchronized are communicated from the lo- 
cal synchronization policy 310 over the network 304 to 
the remote synchronization policy 320. 
[0050] In some embodiments, after the principal 330 
has been out of communication with the remote creden- 

10 ttal store 303 for any period of time and then re- estab- 
lishes communication via the network 304, appropriate 
portions of the local synchronization poiicy 31 0 are im- 
mediately communicated to establish a new instance of 
the remote synchronization policy 320. This new in- 

'5 stance of the remote synchronization policy 320 permits 
an identity service associated with the remote credential 
store 303 to generate a new and active Instance of the 
remote credential store 303 and synchronize appropri- 
ate portions or the remote and local credential stores 

2° 303 and 302, respectively, 

[0051 ] In one embodiment, the locai credential store 
302 services multiple principals 310 and is accessible 
via a server or service to each of the multiple principals 
330. In this embodiment, the local orodeniiat store 302 

55 manages each unique principal 330 with uniquely en- 
crypted records; where each encrypted record is en- 
crypted in a format only know to its associated principal 
330. Thus, the distributed management system 300 can 
be used by a single principal 330 or by multiple princi- 

30 pals 330 within a local neiwork with one another. 
[0052] FIG. 4 Is a diagram of a distributed credential 
store 400. The distributed credential store 400 is imple- 
mented In a computer readable medium and is acces- 
sible over a network 415. The distributed credential 400 

35 is logically assembled and coordinated over the network 
415 and is represented within a local environment of one 
or more principals as one or more local credential stores 
425 and represented external to the local environments 
as a remote credential store 41 1 . 

40 [0053] The distributed credential store 400 includes 
principal identifier fields 401 and credentialing informa- 
tion records 402. Each principal identifier field 401 is ca- 
pable of housing a principal identifier value. Each unique 
principal identifier value is associated with credentialing 

-« Information housed In the credential information record 
402. 

[0054] The credentialing information houses authen- 
tication information, authentication techniques/ servic- 
es, attributes, and policies that define authenticate n 
and interactions between a particular principal identified 
by a principal identifier value of e principal identifier fieid 
401 vis-a-vis a different principal In one embodiment, 
the authentication information and authentication tech- 
niques/ services defined in any particular credent iaiir.g 
55 information are represented as a certificate, in some 
cases, the certificate can be expressed as a SAUL or 
Liberty assertion 

[0055] An initial instance of the distributed credential 
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cipal. 

[0061J In one embodiment, a policy associated with a 
distributed credential store 400 may insist that any in- 
stance of the local credential store 425 be removed from 
5 a processing device of the principal 420, in these situa- 
tions, the focai credential store 425 is removed from the 
processing device when the principal 420 logs off of or 
terminates (normally or abnormally) a session with the 
processing device. However, in this embodiment, all 
io changes occurring with the local credential store 425 are 
synchronized to the remote credential store 411 before 
the local credential store 425 is purged from the 
processing device. This particular embodiment may be 
especially useful when the principal 420 is accessing 
[OOSer^Syncnronization occurs via a synchronization is and creating an instance ot the local credential store 425 
policy, which is managed and controlled bythe principal from a processing device, such as a kiosk 
service 420 This policy is communicated from the prin- f0062) The distributed credential store 400 permits 
cipal service 420 to the Identity service 410 and permits principals to have access to needed credentiahng infor- 
the identity service 41 0 to generate active instances of mation from their local and personal computing environ- 
a remote credential store 41 1 . The remote credential so ments at all times. Thus, a principal has neededcreden- 
store is managed by the identity service 41 1 and corre- tialing information for interacting with another principal 
spends to those portions of the distributed credential even when the principal falls out of direct communica- 
tion with the identity service 41 0. The pri^^^ 
synchronizc with the remote credential store 411 when 
2$ it re- establishes communication with the identity service 
410 and communicates its synchronization policy. Any 



store 400 is created or instantiated by an identity service 
410 when requested from a principal service 420 (pull 
mode!) or when requested by a different principal on be- 
half of a particular principal (push model). Once an initial 
created instance of the distributed credential store 400 
is established, it is managed within the local environ- 
ments of the principals by the principal service 420 as 
one or more local credential stores 425. If the principal 
service 420 falls out of communication with the identity 
service 401 for any period of time, the identity service 
can re-synchronize the local credential store 425 as 
soon as communications are subsequently re-estab- 
lished between the identity service 41 0 and the principal 
service 420. 



store 400 that are defined in the synchronization policy 
which arc to be synchronized in the local credential store 
425. 

[0057] The remote credential store 41 1 is assembled 
and locally linked to appropriate records housed in one 
or more identity stores 411 A and411B. When the iden- 
tity service 410 detects that changes defined in the syn- 
chronization policy occurto records being tracked in the 
distributed credential store 400, these changes are 
communicated to the principal service 420 for update to 
the local credential store 425 or these changes are up- 
dated to the appropriate records of the one or more iden- 
tity stores 41 1 A and 41 1 B (in cases where the changes 
are detected as occurring within the local credential 
Store 425). 

[0058] The principal service 420 also maintains a 
number of credantialing information records 402 in the 
iocal credential store 425 which are not communicated 
and synchronized to the remote credential store 411. 
This is useful when a particular principal is maintaining 
personal credentialing information which it does not de- 
si re the identity service 41 0 to know about or to man age . 
[0059] All communications occurring between the 
principal service 420 and the Identity service 410 are 
performed according io a trust specification which can 
be inspected and validated for each communication. 
This permits both the principal service 420 and the iden- 
tity service 41 0 to satisfy their selves that communica- 
tions are legitimate and authorized. 
[OOGO] In some embodiments, the principal service 
420 resides as a server application or service to multiple 
principals, in these embodiments, the local credential 
store 425 can be segmented into records associated 
with each unique principal being serviced, where sets 
ot the records associated with any particular principal is 
encrypted in a format only known to that particular prin- 



conflicts can be resolved by a global contract or giobal 
policy associated with a particular principal and main- 
tained and managed by the identity service 410. 



1. A computer-implemented method for managing a 
!5 distributed credential store, comprising; 

associating (110) portions of an enterprise cre- 
dential store to a principal credential store; 
selectively synchronizing (120) changes be- 
to tween the portions and the principal credential 

store; and 

managing (130) conflicts and the changes ac- 
cording to a policy. 

45 2. The method of claim 1 wherein the associating fur- 
ther includes: 

aggregating (111) the portions from the enter- 
prise credential store, wherein the portions are 
50 identified by the policy: and 

transmitting (112) the portions to a principal as 
an initial instance of tho principal credential 
store. 

ss 3. The method of claim 1 further comprising: 

inserting (121) personal identity information in- 
to the principal credential store; and 
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preventing (122) the personal identity informa- 
tion from being synchronized with the enter- 
prise credential store. 

4. The method of claim 1 further comprising: s 

detecting (123) an Insertion of new identity in- 
formation into the principal credential store: 
and 

updating (123) the enterprise credential elore 10 
with the new identity information. 

5. The method of claim 1 further comprising: 

detecting (124) an insertion of new identity in- is 
formation into the enterprise credential store; 
determining via the policy that the new identity 
information is included within the portions: and 
updating (124) the principal credential store 
with the new identity information. 20 

6. The method of claim 1 further comprising: 

receiving (1 32) modifications to the policy from 
a principal; and 25 
adjusting (132) the synchronization between 
the portions and the principal credential store 
based on the modifications. 

7. The method of ciaim 1 further comprising using a so 
trust specification (301) to ensure Interactions be- 
tween the entity credential store and the principal 
credential store are initially and remain trusted dur- 

; ing the interactions. 

35 

8. A computer-implemented method for managing a 
distributed credential store, comprising: 

establishing (210) a trust relationship with a re- 
mote credential store (303): 40 
receiving (220)changes associated with one or 
more entries in the remote credential store into 
a local credential stor (302) ; and 
transmitting (230) changes associated with one 
or more entries In the local credential store to is 
the remote credential store. 

9. The method of claim 8 further comprising maintain- 
ing (223) selective sets of the one or more entries 
within the local credential store (302) for separate so 
unique principals (330). 

10. The method of claim 8 further comprising identifying 
(224) for the remote credential store (303) the one 

or more entries In the remote credential store which ss 
are to be received as the changes - 

11. The method of ciaim 10 further comprising manag- 



ing (225) one or more personal identity information 
entries within the local credential store (302) which 
are not trans mitted as tha changes associated with 
the one or more entries in the local credential store 
to the remote credential store (303). 

12. The method of claim 8 further comprising managing 

(221) portions of the local credential store (302) 
from memory and managing other portions from 
storage. 

13. The method of claim 8 further comprising managing 
(225) the trust relationship between the local cre- 
dential store (302) and the remote credential store 
(303) using a trust specification (301). 

14. The method of claim 8 further comprising managing 

(222) the received changes and the transmitted 
changes using a synchronisation policy (310,320). 

15. A computer-networked distributed credential man- 
agement system (300). comprising: 

a trust specification (301); 

a local credential store (302); and 

a remote credential store (303); 

wherein the local credential store and the re- 
mote credential store interact with one another ac- 
cording to the trusl specification, and wherein por- 
tions of the remote credential store are synchro- 
nized with portions of the local credential store, and 
vice versa. 

16. The distributed credentiai management system of 
claim 15 further comprising a remote synchroniza- 
tion policy (320) that determines which of the por- 
tions of the remote credential store (303) are syn- 
chronized with the portions of the local credentiai 
store (302), and wherein the synchronization policy 
is accessible to the remote credential store. 

17. The distributed credential management system of 
claim 16 further comprising a focal synchronization 
policy (310) that determines which portions of the 
local credential store (302) are synchronized with 
Ihe portions of Ihe remote credential store (303). 

18. The distributed credential management system of 
claim 1 6 wherein the remote synchronization policy 
(320) is defined by and modified by the loca! cre- 
dential store (302). 

19. The distributed credential management system of 
claim 15 wherein the focai credential store (302) re- 
sides within a local processing snvironmenf of a 
principal (330). 
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20. The distributed credential management system of 
claim 15 wherein the local credential store (302) is 
managed by a policy and includes multiple records, I 
wherein each record is associated with a different 
principal, and wherein each record is uniquely en- s 
crypted for each different principal. 

21 . A distributed credential store, residing in a compu- 
ter- readable medium, the distributed credential 
store used to acquire credentiaiing information as- »o 
sociated with a principal, the distributed credential 
store comprising: 

a principal identifier field (401 ) capable of hous- 
ing a principal identifier value that identifies a 
particular principal; and 
a credentiaiing information record (402) asso- 
ciated with the principal identifier field and ca- 
pable or housing credentiaiing information as- 
sociated with the principal identifier vaiue for 20 
the particular principal; 

wherein the distributed credential store is ini- 
tially generated by an identity service (41 0). 

SS 

22. The distributed credential store of claim 21 the cre- 
dential data store is maintained remotely by the 
identity service (41 0) and maintained locally by a 
principal service (420). 

30 

23. The distributed credential store of claim 22 wherein 
; some portions of the credentiaiing information (402) 

which are maintained locally are not also main- 
tained remotely. 

24. The distributed credential store of claim 22 wherein 
portions of the credentiaiing information (402) 
which are synchronized and maintained both re- 
motely and locally are defined by a policy which can 

be dynamically modified and initially set by the prin- to 
cipal service (420). 

25. The distributed credential store of claim 21 wherein 
the identity service (41 0) uses the principal identifier 
field (401 ) to construct multiple unique local creden- « 
tial stores (425), each unique local credential store 
associated with a unique instance ol the distributed 
credential store. 

26. The distributed credential store of claim 21 wherein so 
the identity service (410) populates the credential 
information of the credential record (402) by aggrc. 
gating identity information from one ormore identity 
stores associated with the particular principal. 

35 

27. The distributed credential store of claim 21 wherein 
the identity service (41 G) and a principal service 
(420) cooperate to selectively synchronize portions 



of the credential information between one another. 

i. A computer program product which when executing 
on a computer network performs the method of any 
one of claims 1 to 7 or claims 8 to 14. 
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